New pattern - apigw-lambda-bedrock-guardrails-cdk#3113
Conversation
…rdrails Deploy a REST API that invokes Bedrock with per-request Guardrails for content and topic filtering. Each InvokeModel call passes guardrailIdentifier and guardrailVersion for fine-grained control. Differentiates from bedrock-guardrails-cross-account-cdk (account-level) by applying guardrails at the application level per-request. Deployed and tested on live AWS account.
|
Seems to be a duplicate of #3067 |
|
Not a duplicate -- they're different layers of the same feature. #3067 is account-level enforcement (PutEnforcedGuardrailConfiguration -- guardrail applies to ALL Bedrock calls in the account without any code changes). This PR (#3113) is application-level guardrails (individual Lambda passes guardrailIdentifier in each Converse API call). Different use cases: #3067 for org-wide compliance, this one for app-specific content filtering where you choose which calls get guarded. |
|
Thanks @NithinChandranR-AWS for the additional context. You're right that this isn't a duplicate of #3067 |
3 participants
Description
Deploy a REST API that invokes Amazon Bedrock with application-level Guardrails — per-request content and topic filtering.
Application-level vs Account-level
This pattern applies guardrails per-request by passing
guardrailIdentifierandguardrailVersionin each InvokeModel call. Different APIs can use different guardrails or skip them entirely. For account-wide enforcement, seebedrock-guardrails-cross-account-cdk.What it does
Testing
Deployed and tested:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.